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(54) System for oohtcxt-depondont name resolution 



(57) A context-dependent, multiply binding name 
resolution system. A name resolver is provided, con- 
nected to either a requester's system or a receiver's sys- 
tem, or both. Requests to a given service or domain 
nama are resolved to the appropriate IP address. The 
intended recipient of the request is resolved based upon 
a combination of one or mora (VftrlAter mined criteria, in- 
cluding: information aboutthe sender (e.g. geographical 



location, specific requester identity etc.); information 
about the intended recipient (e.g. toad oafanve Uih 
receiver, type of service, etc.); information contained 
within the request lt6elf (e.g. type of service requested): 
or other Information (time of day, date, random selection 
of recipient, e.g.). The system is implemented in hard- 
ware and/or software, and the resolution criteria can be 
mads interdependent or Independent. 
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Description 

Hi is invention related to systems for context-de- 
pendent name resolution. 

In a network (either Intranet or Internet) system, 5 
when a hoot wants to communicate urith another host or 
locate a service or another host on ihe network, the ad- 
dress is typically resolved in an absolute manner that 

is, the naming service of (he network resolved a given 

name to a single iP (Internet Protocol) address. For in- 10 
stance, a domain name sen/ice (DNS) call resolves a 
name to a single IH address or host name on the inter- 
net. 

When there are many connections to a given host 
or service, the resulting congestion degrades the overall 
performance. The service provider may upgrade the 
service, e.g. to increase ite capacity. In this case, in or- 
der to keep the modification of the service transparent 
to requesting hosts, a demultiplexer may be used, as 
illustrated by way of example in Figures 1-2. For in- ^ 
stance, In Figure 1 a call to Service 3 will be uniquely 
resolved to that service's IP address and transmitted 
IMury accordingly, because there Is only a single binding 
in the DNS name resolver to the host of Service 3. In 
general, in a conventional system such as that illustrat- 2S 
ed in Figures 1 . 2 and 2A, there wilt be a single binding 
between a name and an IP address. 

Yet another alternative is for a special type of de- 
multiplexer, which may monitor the traffic, and from the 
different IP addresses can collect statistics such as re- 3Q 
spons© time and/or the load on thB corresponding IP 
hosts, and use this information for load balancing by 
binding a requested name to an IP address for a host 

which ic lace hoavfly I Dad ad. 

If Service 3 Is upgraded to Include Services 3.1 as 
through 3.Y, then the demultiplexer Is added (see Figure 

2)1 lire rwjUfcWling ui DNS rwsolvjny husl iusuIvbs llitr 

request as usual and sends it out over the (Inter- or In- 
ternetwork, but the demultiplexer is interposed be- 
tween the network and the servicers), to route the in- #> 
coming requests to one of the services. Note that in this 
case, there is still a single binding between the DNS and 
the demultiplexer. 

A problem with this approach is that the demulti- 
plexer acts as a limiting factor on throughput, and add)- 45 
tfonaily represents a single source of failure for all of tho 
services that it serves. A mechanism is needed whereby 

ouoh o critical point end bottleneck oar) be avoided, 

while still providing access to the services for remote 
users. 60 

An ailoinalivo approach to decreasing congestion 
is through DNS spoofing, where the name resolve r is 
fooled Into giving out a different name binding, by keep- 
ing the name resolver updated frequently with a new 
name resolution binding based on some criteria such as £5 
load distribution on target servers. An example ot DNS 
spoofing Is shown In Figure 2A, in which a requester 2 
issues a request using the name f sun,com B , and a DNS 



2 

lookup 4 looks it up, The host (1 . 2 or 3) to which the 
names is bound will depend upon criteria employed at 
thg destination domain, as determined by DNS spoofing 
service 6. Such criteria may Include load on the hosts, 
their availability, etc. The DNS spoofing service 6 polls 
tho hocie 1-3 periodically or at demand, and bindo ono 
of them at a time to the DNS lookup name resotver for 
the name *s un.com". 

In a spoofing suivk;u, Lht* uiflyrfa u&eu* (o achieve 
the binding are not related to the context of the request- 
er; thoy roly only upon information at the destination. 
Thus, much information that could be important In mak- 
ing a binding fs not utilized, tn none of the known sys- 
tems is caDer context used. 

It would accordingly be advantageous to have a 
system which takes into account the context of the re- 
quester in the process of name rftftolullnn 

various respective aspects and features of the in- 
vention are defined In the appended claims. 

A oontoxt-dopondont namo rocolution eydtom lo 
presented, which Implements predetermined criteria for 
static or dynamic binding of a "name" to any one of sev- 
eral "objects'' of trie same type. Which "object" Is select- 
ed for the binding is determined by a 'name resotver" 
using context information that is explicitly specified by 
the requestor fn a name resolution lookup call to the 
'name resolver". The "name resotver", which Is Imple- 
mented as a server program, stores a lookup table com- 
prising bindings of a "name" to several different Instanc- 
es ot an object, along with ■policy" information which do- 
fines the criteria for selecting an instance of the object. 
For instance, the name may be an internet URL ol the 
form 'www.sun.com", and the resolved to object may be 

an IP addroee of tho typo 192.1*16.85.92. Thue tho 

"name resolver" will store the tuple: <www.sun.com> 
<IP_address_1> <IP_address_2>..., and will store pof* 
iuiea or i which IP address to bind to www.&uacom when 
a lookup request specifying "www.sun.com* is received 
by It. 

By enabling multiple binding support in the "name 
resolver 1 , several advantages are realized. First, the 
system enables new resources to be added transpar- 
ently to the caller. When a new server is added to dis- 
tribute the load for one or more hosts corresponding to 
the name "sun.com", for instance, the IP address for the 
now server is simply added to the tuple in the name re- 
solver, along with any desired policy criteria, e.g. to use 
only between 9 a.m. and 5 p.m, 

Secondly, the fundamental lima to scaling which is 
Inherent In today's 6 ingle binding systems is removed, 

by enabling multiple destination servers providing tho 

same service to bo referenced by the same "name* han- 
dle by the caller (for example 'aun.com'), and the name 
to be resolved by the name resotver to different physical 
computers servers, depending upon caller context. 
Many Instances of the name resolver may be running 
on different physical computers, and many instances of 
the services may be running, and the requester will ac- 
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cess the name resolver closest to him; and the resolved that can be implemented singly or in any combination 
object that is closest to the requester or that can best with one another multiple binding of destination ad- 
serve the request (based upon some selected orprede- dresses to names; caller context name resolution in con- 
termined criteria) will be bound to the request all trans- nectlon with such multiple binding; and name resolution 
parently to the requester. Another advantage of the sys- 5 policy considerations, l,e. independent criteria upon 
torn of the invention is that it attows resources to be ©as- which such resolution ic baeod. 
ily replicated transparently to the user, eliminating any 

single point of failure in the network or at the service end . Name Resolution : An Example 

point. If ona Yalld destination fails, ra not responding or 

fe overloaded, the name resolver is already capable of w An example of name resolution occurs, for instance, 

binding a "name* to multiple destinations, and the una- whan a user wishes to view video, e.g.a movie, on his 

vailable destination can be disabled in the name resolv- or her computer. An application running on the computer 

er's internal tables, using administrative means. is used to make a procedure call to the name resolver 

The context that may be used as s basis tor the to determine which server can serve a movie, e.g. 

binding Is variable; ft may Include information about the is service Jiandle = name_serviee Jookup( d movie") 

requester (e.g. requester IP address, domain name or where the string "movie" is passed to a server, which 

inferred geographical region), about the destination then returns the name of the service providing thatmov- 

(wrth similar alternatives), about the request itself (e.g. te (or it may return a linked list of services providing mov- 

type or quality of service requested), or about Independ- Ee services, from which the user may be prompted to 

©nt information (e.g. tlm©of day or tlm© zone of the point 2t> select one). 

of origin of the request). The server may, by way of example, return a single 

The system may be implemented (eg as pan of a service name (e.g. 'quicklime*) in the variable called 

computer apparatus) using hardware, software, or com- "acrvice_handlc". Next, the application must determine 

binations thereof. which server host can provide this service to this client; 

The invention will now be described by way of ex- 2S to do this, it makes another name resolution call; 

ample with reference to the accompanying drawings, hostjiandie = namejiostname.iookup 

throughout which like parts are referred to by Flke refer- (servlce.handle) 

ences, and in which: and passes ft the variable ■sarvicejwidla" returned by 

Figures 1 -2A are diagrams of present network sys- the previous call This call returns It the name Of a server 

terns used for destination addresses for requests. so which is listed as offering this service. 

Figure 3 is a flow chart niust rating a method accord- The network location of this server must now be de- 

ing to an embodiment of the present invention. termined, so that the users computer or workstation can 

Figures 4 and 5 are diagrams of network systems connect to it to get the movie service, and so it makes 

Incorporating features of embodiments of the present in- the calf: 

verrtion. 9$ hostJP_address = nome_hostaddress_lookup 

Figure 6 in an illustration of the operation of an em- (hostjnandle) 

boidlinent of the Invention using geography-based ree- and finally obtains on IP oddrciso of on appropriate hoot 

olution criteria. that can provide the movie service to the user, 

Figure 7 is a diagram depicting zones In which do- Further calls to this quicktime server may determine 

mam name service resolvere and service location re- *o a net or movies mat are available. Alternatively, a design 

solvers of the invention may be located, may be had in which the caller simply specifies the name 

A method according to the invention ia illustrated in of the movie he wBnts to see* and the name lookup re- 
Figure 3, and Figures 4-5 shows a suitable systems Im- turns to the caller the IP address of a host that is cur- 
plamentable on the internet or WorfdWide Web, the In- rently able to serve the requested movie to the caller, 
temetoran Intranet,, Incorporating features of the name 4$ All of or some of the above steps may be combined 
resolution system. in more integrated calls to the name resolver. 

Name resolution can Include any kind of name res- In the present invention, tn addition to the above, 

olution lookup for binding np« nhjnnt tn annthar This in* an addhionftl paramATer Ift pa&AAd To the 

eludes binding the name of a service to a host computer nameJiostaddressJookupO function above (or to all 

(or its IP address) that provides that service, and binding so the lunctlons above); this parameter may be called the 

the type of service to the name of a aervioo providing oallor^eontoxt. Thio oollor^oontoxt ic uood by tho namo 

that type of service, ft also Includes resolving a name in resolverto help it decide which IP address to use. Thus, 

one domain to another name In the same domain, and the calls would look like: 

to another name in a different domain. For the puipoaua huaUP-^^kJ^** = nameJnoataddie&Oookup 
of this invention, tho terms "service 0 and •host" can be & (hostjiandie. caIIer_context). Cal)er_context is a cook- 
considered synonymous, as can "service location" and lo (or struct ure) that may Include Information such ae the 
•host location'. caller's IP address, rts polni or origin, tne quality of the 
The system Includes three fundamental features requested service, or any other context that might be 
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relevant. These contexts must be well specified and 
their format(s) standardized, so that many different 
name revolvers can interoparaie property. The particu- 
lar caller.contaxt formats and contents selected are not 
themselves crucial, & 

Tho prASQnt ftmhodirriant uses requester context- 
dependant Intelligence to determine which of several 
destination hosts should be utilized, or rn other words, 
which of severs 1 1 P addressee should be used to resolve 

a given "name - request. The context-dependent inteM- to 
gence, implemented as hardware or software or a com- 
bination ot ooth, allows the "name' resoiuiton to be 
based upon some context information from the reques- 
tor, and/br upon tha "name" being resolved in a context- 
free manner, but optionally dependent upon criteria ts 
such as load balancing on the destination. 

As shown in Figure 4. a requesters 100-120. of 
which there may be an arbitrary number, each comprise 
computers or workstations on a beat network, served 

by a server 1 50. The requestors will typica.lt/ bo conuon- SO 

tional workstations, personal computers, or any net- 
workable computing device, with local proceseors (130, 
etc.). memory (1 40, etc.), mass storage (not shown) and 
network connections. The server 150 also includes a 
conventional processor 160 r msmory 170, mass stor- B$ 
age ana necessary connections and control hardware 
and software. 

A name resotver 180 forms part of the server 150, 
or may be a separate unit. It may be implemented en* 
tirely In software, i.e, as program modules stored In so 
mass storage and/or the memory 170, or it may be a 
standalone device, with its own logic or processor and 
memory, as desired. 

Tho cervor 160 ie connoctod to a broader network 
170, such as the Internet, an Intranet or WAN (wide-area 35 
network), or the Worldwide Web. via a network connec- 
tion (e.g. aT-Miie)2eo.On this nytwvikl70 is optionally 
another name resotver 200, which may be implemented 
in the same fashion or differently from the name resotver 
1 80. Nam© resofvors 1 SO and 200 may both be used, or <c 
either may be used by itself. (See discussion of Figure 
7, below.) 

Destination hosts 21 0-230 may also be convention- 
al computers or workstations with processors (such as 
240). memory (such as 250). mass storage (not shown}, <5 
network connections, etc., as needed to implement con- 
ventional network functions in addition to tho features of 
the prooont invention. 

Referring to the flow chart of Figure 3, whan a re- 
quester (such as 1 00-1 20) sends a name resolution re- so 
quasi tw a name iwsoh/tii 180, Instead of the single bind- 
ing of conventional systems, the name resolver 18Q in- 
cludes multiple binding tables and/or functions (imple- 
mented oy appropriate logfc or program modules) to re- 
solve the request to an appropriate I P address for a das- se 
tmatlon host (such as 210-230 In Figuro 4). 

An example ot such a multiple binding would be tne 
binding of multiple, geographically disparate destlna- 
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tions to a single domain name. If, for instance, a user in 
Germany wishes to access www.sun.com (the WWW 
serverforSun Microsystems. Inc.). heorshecan simply 
use the Uniform Rasounce Locator (URL) "httpy/www. 
sun.com 1 ). Thus, tho user sends the request from re- 
questor 310 (soo Figure 6), and tho name recolvor 320 
determines that the requester is in Germany. (See step 
20 in Figure 3). The selected destinetton may either be 
fn the United States or elsewhere in Europe, trince Sun 
Microsystems in this example has two "sun.conY loca- 
tions. Since there is a valid European local destination 
330, the name resolver 320 resolves the destination ad- 
dress to sun.com (Europe), as indicated at box 30 of 
Figure 3, This resolved destination is then selected for 
the request packet(s) (box 40 of Figure 3), and the re- 
quest Is forwarded to sun.com (Europe) (box 50 of Fig- 
ure 3), 

Following are lists of context-dependent resolution 
criteria applicable to the invention and usable at box 30 
of Figure 3, whore resolution may be based upon re- 
quester Information, destination information, request 
contents, or other information: 

A. Resolution Based Upon Requester Information 

examples ot manners tn wmcti Che resolution de- 
pendent upon requester information may be carried out 
include: 

1. resolution based upon the domain name of the 
sender: 

2. resolution based upon the inferred (looked-up) 
actual geographic region of the sender; 

3. resolution based upon other geography-related 
information of the sender: 

4. either directly ascertainable from the nequeat 
(city/country info, e.g.); sndtor 

5. indirectly ascertainable (area code, address, 
etc.); 

6. resolution baeed upon quality of service dosirod 
by the requester; end 

7. resolution based upon requester's time of day or 
time zone, 

B. Resolution Based Upon Destination information 

Examples of manners in which the resolution de- 
pendent upon a specified or intended destination or re- 
ceiver information may be carried out include: 

1. resolution based upon the load at the receiver; 

2. reeutuLiuri based upun Lilt? in I cried (Icroked-Up) 

actual geographic region of the receiver; 

3. resolution basod upon Other geography-related 

intormation of the receiver: 
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4. either directly ascertainable from the request 
(city/country info, e.g.); and/or 

5. Indirectly ascertainable (area code, address, 
etc.). 

5 

Criterion B. 1 can b© rocnfvorl oitharhflBorl upon In. 
formation as perceived at the sender end or based upon 
information as it exists at the receiver end, and resolved 

at the ©ender end. For example, tha sender might fro 

quently send requests toaparticular server, service, ge- w 
ographical region or organization. In this case, it may be 
advantageous to regularly poll one or more often-used 
destinations to determine their level(s) of activity. Alter- 
natively, such pofling could automatically be carried out 
for any destinations for whfch the sender determines 
that its number of requests exceeds a certain threshold, 
or for a top predetermined percentage of requests sent 
by the requester (e.g. all destinations for which the 
number of requests exceeds N1% t or the top N2 desti- 
nations tn whinh tho sondnr rrtakos rnqi JAStft, whfcTA N 1 SO 
and N2 are appropriate predetermined numbers). Poll- 
ing can be implemented as program modules Integral to 
the name resolver(s), either entirely in one or in mora 
than one location (e.g. partially in a local name resolver 
and partially in the destination server). 2S 

Alternatively or in addition, criterion B.1 may be 
based upon Information at the receive end at the time 
of sending the request, and resolved at the receiver. 

C. R&sotuVron Based Upon Request Contorts 30 

1 . type of service requested; 

2. specific information (or type of information) re- 
quited; 

3. any other implicit information inferredfram the re- & 
quest; and/or 

4. any other explicit information obtained from the 
request. 

D. Resolution ueoenoent Upon other Facrors «> 

1. randomly generated selection of destination 
based upon qualified list; and/or 

2. other Independently developed Information, 

46 

Thoso resolution criteria can be used singly or in 
any desirod combination with one another; as specified 

by the- requestor or the admin istralor of the destination 

(e.g. server owner or service provider). For instance, in 
the example of Figure 6 the resolution of the destination r so 
address to &un.com (Europe) coutd bo modified if tho 
load of sun.com (Europe) is larger by some predeter- 
mined threshold amount than the load at sun.com (USA) 
in which case the sun.com (USA) resuiuiimi uould 
override the default sun.com (Europe) resolution for re- «* 
questers tn Europe, either at all times or only during 
peak European hours, which correspond to off-pea k 
hours in the United States. 
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An extension of this system is in the resolution of 
services provided at the receiver network of a request. 
For instance, a given organization may have many da- 
tabase servers, and request for access to given Infor- 
mation may fn conventional systems be routed to the 
Rama fcorvar, horanfco of the slnrjla hlnrllng nattira of 
destination resolution. With multiple address resolution 
binding, multiple database servers (or other destination 
hoota) ouch do 210, 270, 2B0, oto. (aoo Figure £) may 

be made available under a single name, in which case 
a local service resolution server such as server 300 in 
Figure 5, Is provided. The server 300 Includes tables, 
program modules or the like as desired to resolve a re- 
quest to any one of several to many IP addresses. The 
selection of a given server to receive a request can de- 
pend upon, for example, load at each of the servers. 

In general, the resolution systems or subsystems 
wiB be in one of three "zones" (see Figure 7); the send- 
er's zone 1 (up to, e.g., the sender's firewall or Internet 
AftrvAr); the name rR<wlvfir system's 7one 9 (whlr^h may 
be at a server on the Internet, or any place outside zone 
1 which is not in the receiver's system; and the receiver's 

zone 3. Service location namo rcsotvors may bo in any 
of zones 1 -3; typically, destination lookup name resolv- 
ers, which may comprise multiple-binding domain name 
services (DNS'e), will be in either zone 1 or zona z, it 
will be understood that zones, for the purpose of this 
application, are administrative boundaries, and need 
not correlate to actual network boundaries. 

The present embodiment can interact with existing 
systems in a number of ways. For instance, In secure 
systems where the source address is stripped from the 
request by a firewall (and only, e.g., the domain name 
remains), than tha antim smirch Address would not be 
used to resolve the destination; the name reeolver is 
provided with the program Instructions or circuitry to im- 
plement thlc. Noto also that the DNS name resolution 
may be a distfnet operation from service location, and 
thus the destination can be selected due to a combina- 
tion or considerations iifeludlng source address, re- 
quested destination address, and request contents, in- 
cluding the type of request made or service requested. 

The multiple binding feature of the invention allows 
a single name, Internet address (e.g. URL address such 
as http://www,eun.com) or the like to represent as many 
actual servers (or services) as desired. This has a dis- 
tinct advantage of allowing modifications, upgrades or 
replications to be made to the destination server(s) with- 
out modification ot thB destination address or service 
name as used by the requester. Such modifications may 
incl li do adding corvore or services, or establishing a mir- 
ror site at a location geographically near a large source 
of requests, etc. 

There may bo security and conaiaienoy impliootionc 
of multiple bindings, with concomitant solutions. If a des- 
tination address can bo multiply bound, a namo rosolvor 
may be cgnHuurud lu bind to an Incorrect addrooe, oithor 
deliberately or otherwise. While this may ai90 be a prob- 
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lem witn existing single binding, multiple binding may 
complicate detection of the problem. Thus, tha system 
of tha invention may be combined with programs and 
tables for verification that a given binding is valid. Very 
secure systems may wish to limit their multiple binding 
to & predetermined, fixed number nf rafinlntlort possibil- 
ities, or even maintain the current system of single bind- 
ing as far as Internet or Web transmission is concerned, 
and implement multiple binding only behind a firewall. 
Alternatively or in addition, encryption and digital signa- 
tured may be used to ensure validity of bindings, and of 

modifications or additions to the bindings. 

variations may be had by designating a given name 
resolution as a default resolution, and utilizing alterna- 
tive resolutions only upon the request meeting prede- 
termined criteria (such as load imbalance, geographical 
distance, specific sources of the request, etc.). 

Additional bindings (i.e. additional addresses to 
which a request may resolve) may be added without the 
requester being aware of it, and indeed Auhstrtirtinn* 
may be made at any time, again transparently to the re- 
quester. 

F Service Selection Based Upon Caller Context 

The system or l/ie invention may be applied more 
generally to the use of caller context for name resolution. 
Context about the requesting user (e.g. in a variable 
called 'caller.contexT) can be passed to appropriate 
functions, such as: 

service_handle = name_$en/fceJookup( 1 movie , \ 
calleccontext) 

hostjnandle = namajiostnamejookup 
(J59rvic9_handifl ) calter_eontext) 
Herd, the function eervfcejiandle executes a service 
name lookup based upon the input "movie", as well as 

the information in the vgriablo callcr_contCKt, outputting 
the value servicejiandle. Given this output as input, 
along with (again) caller_context ( the function 
host_hanrJle then returns an appropriate host name. 

An example of a possible such situation could result 
when a user desires an encryption service, and several 
encryption policies are available. The servlcejiandle 
function can be configured to return different encryption 
algorithm services based upon the specified destination 
(which is specified in caller.context), or there may be 
an effective override in tho callcr_contoxt by which tho 
unfit ran RHlftrt r htQhftr Iftvftl of security 

In general, as noted above, the invention may be 
Implemented at the sender's system or at the destina- 
tion cy&tom, or indoodat pofnte in botwoon (a.g. at proxy 
servers). Note that single points of failure and bottle- 
necks are removed ualngthe present system, andatruly 

dislribuLud, multiply binding nam a lusoluliorl system to 

achieved. 

Part fcular and preferred aspects of the invention are 
set out in the accompanying independent ana Depend- 
ent claims. Features of the dependent claims may be 



combined with those of the independent claims as ap- 
propriate and in combinations other than those explicitly 
set out in lha clafms, 



Claims 

1 . A system for name resolution of at least one request 
directed to a destination namu uf a receiver and 1s- 
10 sued from a requester system, including: 

a name revolver connected to the requester 
service and Including 

predetermined information correlating a plural- 
's Ity of destination addresses wfth said destina- 
tion name; 

a criteria selection subsystem configured to 
provide a selection of at least one said destina- 
tion address based upon at least one predeter- 
mined criterion; and 

a destination address binder configured to bind 
said destination name with said selected desti- 
nation address. 

2B 2. The system of claim i, wherein said at least one 
preaeiermmed criterion includes a cmerion based 
upon Information explicitly contained within said re- 
quest. 

so x The system of claim 2, wherein said information In- 
cludes an address of said requester. 

4. The system of claim 2, wherein said Information Is 
based upon at least a portion of contents of said 
as request. 

£. The oyotom of claim 4, wherein aa id portion of said 
contents includes at least one of: 

*o a type of service requested by safd request: and 

a quality of service requested by said request. 



6. The system of claim 1, wherein said at least one 
predetermined criterion includes a criterion based 
upon information not explicitly contained within said 
request. 

7. Th& system of claim 6. wherein said information 
pertains to a geographical region of said requester 

8. The eyetom of claim 6, wherein said Information 
pertains to a geographical region of said receiver 

9. The eyslem of claim 9, wrw^in &aid information in- 
cluded load Information relating to eald receiver. 

10. Trie system orcoim 6, wneram sara information in- 
cludes at least ono of time and date information. 



45 



so 



SB 
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11. The system of claim 1 T wherein said binding is to a 
port at said destination address. 

12. The system of claim 1, wherein said bfnding is 
based at (east In part upon a random selection of s 
one said destination address 

13. A method for context-dependent binding of a desti- 
nation name to a destination address in a name ro- 
solver having a predetermined set of binding criteria >o 
and predetermined correlations of destination 
names wrtn destination addresses, wherein at least 
one said correlation is a multiple correlation corre- 
lating a plurality of said destination addresses with 

a single destination name, Including the steps of: is 

(1 ) receiving said request at said namo revolv- 
er; and 

(2} based upon eafd multiple correlation, re- 

trrni/ing »t loast nno Aattf destination adoYesS 20 

from said plurality of destination addresses. 

14. The mothoti of claim 1 0, further including after stop 

2, the step of: 

(3) binding said retrieved destination address 
10 said destination name. 



a random factor generated by said name re- 
solver. 

21. A system for name resolution of at least one request 
directed to a destination name of a receiver and is- 
sued from a. requestor system, the requoel informa- 
tion relating to cellar context, the system Including: 

a name revolver connected to the requester 
service and including 

predetermined information correlating a plural- 
ity ol service names with said caller context; 
a service selection subsystem configured to 
provide a selection of at least one said service 
name based upon said caller context; and 
a host name selection subsystem configured to 
return a host namo based corresponding to 
said selected service name. 

22. Trio syotorn of claim 1, wherein eaid at loact ono 
predetermined criterion Includes: 

a first criterion basest! uuum inruirneUion explic- 
it [y contained within said request; and 
a second criterion based upon Information not 
explicitly contained witntn said request. 



1S. The method of oraim 14, further including alter step 23. 
3, the step of: 

(4) transmitting said request with said desti- oo 
nation address. 



The system of claim 22, wherein said second crite- 
rion corresponds to a predetermined policy used by 
sard name resolver. 



16. The method of claim 13, wherein said multiple cor- 
relation ic bacod upon rnfornnation explicitly con- 
tained within said request. 35 

17. Trie system of claim 1 3, wherein said multiple cor- 
relation is based upon at least a portion of contents 
of said request. 

AO 

18. The system of claim 13, wherein said multiple cor- 
relation is based upon at least one of: 

an address of said requester; and 

a type of service requested by said request; and *s 

a quality ol service requested by said request, 

10i The system of Claim 1 , wherein said multiple corre- 
lation Is based upon Information not explicitly con- 
tained within said request. *£> 

20. The system of claim 19, whoroln said multiple cor- 
relation is based upon at teast one of : 

a geographical region of said receiver; & 
load information rotating to said receiver; 
time information; 
date information; and 



24. The system of claim 23, wherein said first criterion 
corresponds to information relating specifically to 

said requestor system. 
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Figure 6 
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